Webb Säkerhetsheaders Implementering: JavaScript Content Security Policy (CSP)

I dagens digitala landskap är webbsäkerhet av yttersta vikt. Att skydda din webbplats och dess användare från skadliga attacker är inte längre ett val utan en nödvändighet. Cross-Site Scripting (XSS) är fortfarande ett utbrett hot, och ett av de mest effektiva försvaren är att implementera en stark Content Security Policy (CSP). Den här guiden fokuserar på att använda JavaScript för att hantera och implementera CSP, vilket ger ett dynamiskt och flexibelt tillvägagångssätt för att säkra dina webbapplikationer globalt.

Vad är Content Security Policy (CSP)?

Content Security Policy (CSP) är en HTTP-svarshuvud som låter dig kontrollera vilka resurser användaragenten (webbläsaren) får ladda för en given sida. I grund och botten fungerar det som en vitlista, som definierar ursprungen från vilka skript, stilmallar, bilder, typsnitt och andra resurser kan laddas. Genom att explicit definiera dessa källor kan du avsevärt minska attackytan på din webbplats, vilket gör det mycket svårare för angripare att injicera skadlig kod och utföra XSS-attacker. Det är ett viktigt lager av "defense in depth" (försvar i djupet).

Varför använda JavaScript för CSP-implementering?

Medan CSP kan konfigureras direkt i din webbservers konfiguration (t.ex. Apache:s .htaccess eller Nginx:s konfigurationsfil), erbjuder användning av JavaScript flera fördelar, särskilt i komplexa eller dynamiska applikationer:

• Dynamisk policysgenerering: JavaScript låter dig dynamiskt generera CSP-policyer baserat på användarroller, applikationens tillstånd eller andra förhållanden i körning. Detta är särskilt användbart i Single-Page Applications (SPA) eller applikationer som är starkt beroende av klient-sidig rendering.
• Nonce-baserad CSP: Att använda nonces (kryptografiskt slumpmässiga, engångs-tokens) är ett mycket effektivt sätt att säkra inline-skript och stilar. JavaScript kan generera dessa nonces och lägga till dem i både CSP-headern och inline-skript-/stil-taggarna.
• Hash-baserad CSP: För statiska inline-skript eller stilar kan du använda hash-värden för att vitlista specifika kodavsnitt. JavaScript kan beräkna dessa hash-värden och inkludera dem i CSP-headern.
• Flexibilitet och kontroll: JavaScript ger dig finkornig kontroll över CSP-headern, vilket gör att du kan modifiera den i farten baserat på specifika applikationsbehov.
• Felsökning och rapportering: JavaScript kan användas för att fånga CSP-överträdelserapporter och skicka dem till en central loggningsserver för analys, vilket hjälper dig att identifiera och åtgärda säkerhetsproblem.

Konfigurera din JavaScript CSP

Det allmänna tillvägagångssättet innebär att generera en CSP-huvudsträng i JavaScript och sedan ställa in lämplig HTTP-svarshuvud på serversidan (vanligtvis via ditt backend-ramverk). Vi kommer att titta på specifika exempel för olika scenarier.

1. Generera Nonces

En nonce (number used once) är ett slumpmässigt genererat, unikt värde som används för att vitlista specifika inline-skript eller stilar. Så här kan du generera en nonce i JavaScript:

            function generateNonce() {
  const crypto = window.crypto || window.msCrypto; // För IE-stöd
  if (!crypto || !crypto.getRandomValues) {
    // Återfall för äldre webbläsare utan crypto API
    return Math.random().toString(36).substring(2, 15) + Math.random().toString(36).substring(2, 15);
  }
  const arr = new Uint32Array(1);
  crypto.getRandomValues(arr);
  return btoa(String.fromCharCode.apply(null, new Uint8Array(arr.buffer)));
}

const nonce = generateNonce();
console.log("Genererad Nonce:", nonce);

            

              
                Copy
              
            
          

Detta kodavsnitt genererar en kryptografiskt säker nonce med webbläsarens inbyggda crypto API (om tillgängligt) och faller tillbaka till en mindre säker metod om API:et inte stöds. Den genererade noncen är sedan bas64-kodad för användning i CSP-headern.

2. Infoga Nonces i Inline-skript

När du har en nonce måste du infoga den i både CSP-headern och <script>-taggen:

HTML:

            <script nonce="YOUR_NONCE_HERE">
  // Din inline-skriptkod här
  console.log("Hej från inline-skript!");
</script>
            

              
                Copy
              
            
          

JavaScript (Backend):

            const nonce = generateNonce();
const cspHeader = `default-src 'self'; script-src 'self' 'nonce-${nonce}' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;`;

// Exempel med Node.js och Express:
app.use((req, res, next) => {
  res.setHeader('Content-Security-Policy', cspHeader);
  // Skicka noncen till vyn eller mallmotorn
  res.locals.nonce = nonce;
  next();
});

            

              
                Copy
              
            
          

Viktiga Anmärkningar:

• Ersätt YOUR_NONCE_HERE i HTML med den faktiska genererade noncen. Detta görs ofta på serversidan med en mallmotor. Exemplet ovan illustrerar att skicka noncen till mallmotorn.
• script-src-direktivet i CSP-headern inkluderar nu 'nonce-${nonce}', vilket tillåter skript med matchande nonce att köras.
• 'strict-dynamic' läggs till i direktivet script-src. Detta direktiv talar om för webbläsaren att lita på skript som laddas av betrodda skript. Om en skripttagg har en giltig nonce, kommer alla skript som den laddar dynamiskt (t.ex. med hjälp av document.createElement('script')) också att betros. Detta minskar behovet av att vitlista många enskilda domäner och CDN-URL:er och förenklar CSP-underhåll avsevärt.
• 'unsafe-inline' avråds generellt från när nonces används eftersom det försvagar CSP. Det ingår dock här för demonstrationsändamål och bör tas bort i produktion. Ta bort detta så snart du kan.

3. Generera Hash-värden för Inline-skript

För statiska inline-skript som sällan ändras kan du använda hash-värden istället för nonces. Ett hash-värde är en kryptografisk sammanfattning av skriptets innehåll. Om skriptets innehåll ändras, ändras hash-värdet, och webbläsaren kommer att blockera skriptet.

Beräkna Hash-värdet:

Du kan använda onlineverktyg eller kommandoradsverktyg som OpenSSL för att generera SHA256-hash-värdet för ditt inline-skript. Till exempel:

            openssl dgst -sha256 -binary your_script.js | openssl base64
            

              
                Copy
              
            
          

Exempel:

Låt oss säga att ditt inline-skript är:

            <script>
  console.log("Hej från inline-skript!");
</script>
            

              
                Copy
              
            
          

SHA256-hash-värdet för detta skript (utan <script>-taggarna) kan vara:

            sha256-YOUR_HASH_HERE
            

              
                Copy
              
            
          

CSP-header:

            const cspHeader = `default-src 'self'; script-src 'self' 'sha256-YOUR_HASH_HERE'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;`;
            

              
                Copy
              
            
          

Ersätt YOUR_HASH_HERE med det faktiska SHA256-hash-värdet för ditt skriptinnehåll.

Viktiga Överväganden för Hash-värden:

• Hash-värdet måste beräknas på det exakta innehållet i skriptet, inklusive mellanslag. Varje ändring i skriptet, även ett enda tecken, kommer att ogiltigförklara hash-värdet.
• Hash-värden är bäst lämpade för statiska skript som sällan ändras. För dynamiska skript är nonces ett bättre alternativ.

4. Ställa in CSP-headern på servern

Det sista steget är att ställa in HTTP-svarshuvudet Content-Security-Policy på din server. Den exakta metoden beror på din serversidans teknologi.

Node.js med Express:

            app.use((req, res, next) => {
  const nonce = generateNonce();
  const cspHeader = `default-src 'self'; script-src 'self' 'nonce-${nonce}' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;`;
  res.setHeader('Content-Security-Policy', cspHeader);
  res.locals.nonce = nonce; // Gör noncen tillgänglig för mallar
  next();
});
            

              
                Copy
              
            
          

Python med Flask:

            from flask import Flask, make_response, render_template, g
import os
import base64

app = Flask(__name__)

def generate_nonce():
    return base64.b64encode(os.urandom(16)).decode('utf-8')

@app.before_request
def before_request():
    g.nonce = generate_nonce()

@app.after_request
def after_request(response):
    csp = "default-src 'self'; script-src 'self' 'nonce-{nonce}' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests".format(nonce=g.nonce)
    response.headers['Content-Security-Policy'] = csp
    return response

@app.route('/')
def index():
    return render_template('index.html', nonce=g.nonce)

            

              
                Copy
              
            
          

PHP:

            <?php
function generateNonce() {
  return base64_encode(random_bytes(16));
}

$nonce = generateNonce();
header("Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-" . $nonce . "' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests");
?>
<!DOCTYPE html>
<html>
<head>
  <title>CSP Exempel</title>
</head>
<body>
  <script nonce="<?php echo htmlspecialchars($nonce, ENT_QUOTES, 'UTF-8'); ?>">
    console.log("Hej från inline-skript!");
  </script>
</body>
</html>
            

              
                Copy
              
            
          

Apache (.htaccess):

Även om det inte rekommenderas för dynamisk CSP, kan du ställa in en statisk CSP med hjälp av .htaccess:

            <IfModule mod_headers.c>
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;"
</IfModule>
            

              
                Copy
              
            
          

Nginx:

            add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests";
            

              
                Copy
              
            
          

Viktiga Anmärkningar:

• Ersätt 'self' med den faktiska domänen/domänerna från vilka du vill tillåta resurser att laddas.
• Var extremt försiktig när du använder 'unsafe-inline' och 'unsafe-eval'. Dessa direktiv försvagar CSP avsevärt och bör undvikas när det är möjligt.
• Använd upgrade-insecure-requests för att automatiskt uppgradera alla HTTP-förfrågningar till HTTPS.
• Överväg att använda report-uri eller report-to för att ange en slutpunkt för att ta emot CSP-överträdelserapporter.

CSP Direktiven Förklarade

CSP använder direktiv för att specificera de tillåtna källorna för olika typer av resurser. Här är en kort översikt över några av de vanligaste direktiven:

• default-src: Anger standardkällan för alla resurser som inte uttryckligen täcks av andra direktiv.
• script-src: Anger de tillåtna källorna för JavaScript.
• style-src: Anger de tillåtna källorna för stilmallar.
• img-src: Anger de tillåtna källorna för bilder.
• font-src: Anger de tillåtna källorna för typsnitt.
• media-src: Anger de tillåtna källorna för ljud och video.
• object-src: Anger de tillåtna källorna för plugins (t.ex. Flash). Generellt bör du ställa in detta till 'none' för att inaktivera plugins.
• frame-src: Anger de tillåtna källorna för ramar och iframes.
• connect-src: Anger de tillåtna källorna för XMLHttpRequest, WebSocket och EventSource-anslutningar.
• base-uri: Anger de tillåtna bas-URI:erna för dokumentet.
• form-action: Anger de tillåtna slutpunkterna för formulärinlämningar.
• upgrade-insecure-requests: Instruerar användaragenten att behandla alla webbplatsens osäkra URL:er (de som serveras via HTTP) som om de hade ersatts med säkra URL:er (de som serveras via HTTPS). Detta direktiv är avsett för webbplatser som helt har migrerats till HTTPS.
• report-uri: Anger en URI dit webbläsaren ska skicka rapporter om CSP-överträdelser. Detta direktiv är föråldrat till förmån för report-to.
• report-to: Anger en namngiven slutpunkt dit webbläsaren ska skicka rapporter om CSP-överträdelser.

CSP Källistor Nyckelord

Varje direktiv använder en källista för att specificera de tillåtna källorna. Källistan kan innehålla följande nyckelord:

• 'self': Tillåter resurser från samma ursprung (schema, värd och port).
• 'none': Förbjuder resurser från vilket ursprung som helst.
• 'unsafe-inline': Tillåter inline-skript och stilar. Undvik detta när det är möjligt.
• 'unsafe-eval': Tillåter användning av eval() och relaterade funktioner. Undvik detta när det är möjligt.
• 'strict-dynamic': Anger att den tillit som webbläsaren ger ett skript på sidan på grund av en medföljande nonce eller hash, ska överföras till de skript som laddas av det skriptet.
• 'data:': Tillåter resurser som laddas via data:-schemat (t.ex. inline-bilder). Använd med försiktighet.
• 'mediastream:': Tillåter resurser som laddas via mediastream:-schemat.
• https:: Tillåter resurser som laddas via HTTPS.
• http:: Tillåter resurser som laddas via HTTP. Generellt avråds från.
• *: Tillåter resurser från vilket ursprung som helst. Undvik detta; det underminerar syftet med CSP.

CSP Överträdelse rapportering

CSP-överträdelse rapportering är avgörande för att övervaka och felsöka din CSP. När en resurs bryter mot CSP kan webbläsaren skicka en rapport till en specificerad URI.

Konfigurera en Rapport-slutpunkt:

Du behöver en serversidig slutpunkt för att ta emot och bearbeta CSP-överträdelserapporter. Rapporten skickas som en JSON-nyttolast.

Exempel (Node.js med Express):

            app.post('/csp-report', (req, res) => {
  console.log('CSP Överträdelse Rapport:', req.body);
  // Bearbeta rapporten (t.ex. logga till en fil eller databas)
  res.status(204).end(); // Svara med en 204 No Content-status
});
            

              
                Copy
              
            
          

Konfigurera report-uri eller report-to Direktivet:

Lägg till direktivet report-uri eller report-to i din CSP-header. report-uri är föråldrad, så föredra att använda report-to.

            const cspHeader = `default-src 'self'; script-src 'self' 'nonce-${nonce}' 'strict-dynamic'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests; report-to csp-endpoint;`;
            

              
                Copy
              
            
          

Du måste också konfigurera en Reporting API-slutpunkt med hjälp av Report-To-headern.

            Report-To: { "group": "csp-endpoint", "max_age": 10886400, "endpoints": [{"url": "/csp-report"}], "include_subdomains": true }

            

              
                Copy
              
            
          

Notera:

• Report-To-headern måste ställas in för varje begäran till din server, annars kan webbläsaren kasta bort konfigurationen.
• report-uri är mindre säker än report-to eftersom den inte tillåter TLS-kryptering av rapporten, och den är föråldrad, så föredra att använda report-to.

Exempel på CSP Överträdelse Rapport (JSON):

            {
  "csp-report": {
    "document-uri": "https://example.com/page.html",
    "referrer": "",
    "violated-directive": "script-src 'self' 'nonce-YOUR_NONCE_HERE'",
    "effective-directive": "script-src",
    "original-policy": "default-src 'self'; script-src 'self' 'nonce-YOUR_NONCE_HERE'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests; report-uri /csp-report;",
    "blocked-uri": "https://evil.com/malicious.js",
    "status-code": 200,
    "script-sample": ""
  }
}

            

              
                Copy
              
            
          

Genom att analysera dessa rapporter kan du identifiera och åtgärda CSP-överträdelser, vilket säkerställer att din webbplats förblir säker.

Bästa praxis för CSP-implementering

• Börja med en restriktiv policy: Börja med en policy som bara tillåter resurser från din egen origin och luckra gradvis upp den vid behov.
• Använd nonces eller hash-värden för inline-skript och stilar: Undvik att använda 'unsafe-inline' när det är möjligt.
• Använd 'strict-dynamic' för att förenkla CSP-underhåll.
• Undvik att använda 'unsafe-eval': Om du behöver använda eval(), överväg alternativa metoder.
• Använd upgrade-insecure-requests: Uppgradera automatiskt alla HTTP-förfrågningar till HTTPS.
• Implementera CSP-överträdelse rapportering: Övervaka din CSP för överträdelser och åtgärda dem omedelbart.
• Testa din CSP noggrant: Använd webbläsarens utvecklarverktyg för att identifiera och lösa eventuella CSP-problem.
• Använd en CSP-validator: Onlineverktyg kan hjälpa dig att validera din CSP-huvudsyntax och identifiera potentiella problem.
• Överväg att använda ett CSP-ramverk eller bibliotek: Flera ramverk och bibliotek kan hjälpa dig att förenkla CSP-implementering och hantering.
• Granska din CSP regelbundet: När din applikation utvecklas kan din CSP behöva uppdateras.
• Utbilda ditt team: Se till att dina utvecklare förstår CSP och dess betydelse.
• Implementera CSP i etapper: Börja med att implementera CSP i "report-only"-läge för att övervaka överträdelser utan att blockera resurser. När du är säker på att din policy är korrekt, kan du aktivera den i "enforcement"-läge.
• Dokumentera din CSP: Behåll en journal över din CSP-policy och anledningarna bakom varje direktiv.
• Var medveten om webbläsarkompatibilitet: CSP-stöd varierar mellan olika webbläsare. Testa din CSP på olika webbläsare för att säkerställa att den fungerar som förväntat.
• Prioritera säkerhet: CSP är ett kraftfullt verktyg för att förbättra webbsäkerheten, men det är inte en "silver bullet". Använd det i kombination med andra säkerhetsbästa praxis för att skydda din webbplats från attacker.
• Överväg att använda en Web Application Firewall (WAF): En WAF kan hjälpa dig att verkställa CSP-policyer och skydda din webbplats från andra typer av attacker.

Vanliga Utmaningar vid CSP-implementering

• Tredjepartsskript: Att identifiera och vitlista alla domäner som krävs av tredjepartsskript kan vara utmanande. Använd strict-dynamic där det är möjligt.
• Inline-stilar och händelsehanterare: Att konvertera inline-stilar och händelsehanterare till externa stilmallar och JavaScript-filer kan vara tidskrävande.
• Webbläsarkompatibilitetsproblem: CSP-stöd varierar mellan olika webbläsare. Testa din CSP på olika webbläsare för att säkerställa att den fungerar som förväntat.
• Underhållsbelastning: Att hålla din CSP uppdaterad när din applikation utvecklas kan vara en utmaning.
• Prestandapåverkan: CSP kan medföra en liten prestandapåverkan på grund av behovet att validera resurser mot policyn.

Globala Överväganden för CSP

När du implementerar CSP för en global publik, överväg följande:

• CDN-leverantörer: Om du använder CDN:er, se till att du vitlistar de relevanta CDN-domänerna. Många CDN:er erbjuder regionala slutpunkter; att använda dessa kan förbättra prestandan för användare i olika geografiska platser.
• Språkspecifika resurser: Om din webbplats stöder flera språk, se till att du vitlistar de nödvändiga resurserna för varje språk.
• Regionala regleringar: Var medveten om eventuella regionala regleringar som kan påverka dina CSP-krav.
• Tillgänglighet: Se till att din CSP inte oavsiktligt blockerar resurser som krävs för tillgänglighetsfunktioner.
• Testning över regioner: Testa din CSP i olika geografiska regioner för att säkerställa att den fungerar som förväntat för alla användare.

Slutsats

Att implementera en robust Content Security Policy (CSP) är ett avgörande steg för att säkra dina webbapplikationer mot XSS-attacker och andra hot. Genom att använda JavaScript för att dynamiskt generera och hantera din CSP kan du uppnå en högre grad av flexibilitet och kontroll, vilket säkerställer att din webbplats förblir säker och skyddad i dagens ständigt föränderliga hotlandskap. Kom ihåg att följa bästa praxis, testa din CSP noggrant och övervaka den kontinuerligt för överträdelser. Säker kodning, försvar i djupet och en väl implementerad CSP är nyckeln till att erbjuda säker surfning för en global publik.